Admissions control is a significant problem in communications networks and especially in connectionless, packet-based, communications networks. For example, consider a particular link in a communications network. If that link becomes congested, the traffic is unable to flow through the link and packets are dropped. This results in deterioration in quality of service for all services provided over that link. In particular situations this has especially severe impact, for example, when the link provides the main access route from a communications network of a particular enterprise or residential customer to a core communications network.
These problems are particularly relevant for voice over internet protocol (VOIP) solutions. If a link is already carrying the maximum number of VOIP calls, or other non-voice traffic, adding additional calls seriously degrades the voice quality of existing calls using that link. The new call added to the link also has poor voice quality. Continuing to add calls to the link degrades the quality of all calls until none of those calls are recognisable.
The term “Voice over Internet Protocol call” is used herein to refer calls involving any suitable type of media over internet protocol. For example, speech calls, fax calls, modem calls or video calls.
FIG. 4 shows a voice over internet protocol (VOIP) communications network in which admissions control is required. A local area network 40 (LAN), or any suitable type as known in the art, is connected via an access link A to a core communications network 42. Any suitable type of access link can be used as is known in the art, for example, Gigabit Ethernet, Digital Subscriber, or leased line. However, link A is unable to support calls into the core from all endpoints in the LAN simultaneously. Those endpoints are said to be “concentrated” behind link A. Concentration can be implemented in network designs for example where many of the calls are anticipated to stay on the LAN behind an access link to a core network and/or where not all of the endpoints will need to make calls into the core network at the same time. In this way a customer's LAN may be connected to a core network via a single access link that supports both voice and data at the same time. In such situations there is a need to detect when over utilisation of the access link is likely to occur in order that preventative measures can be taken. However there are currently no suitable methods for detecting link over-utilisation and communicating this to a call server or other management node in order that link over-utilisation can be prevented.
Another example is illustrated in FIG. 5. In this case an enterprise network 50 is connected via a fixed wireless link 51 to a core network 52. The fixed wireless link has limited bandwidth and is unable to support calls from all endpoints in the enterprise network at one time. In addition varying amounts of bandwidth are required for calls, depending on the type of call required (e.g. voice calls can use a multitude of different codecs, each of which have their own bandwidth characteristics, fax call, etc.) and this further increases the complexity of the admissions control problem.
One known form of admissions control for the “access” portion of a network is found in the Packetcable (Trade Mark) standards for dynamic quality of service (DQOS). Packet Cable is a set of protocols developed by Cable Television Laboratories, Inc. The protocols are designed to enable quality of service enhanced communications using packetised data transmission technology to a subscriber's home over the cable network. A network superstructure that overlays the two-way data-ready digital cable television network is used. The Packetcable protocols are thus specifically designed for such cable television networks. Another disadvantage of these protocols from the point of view of admissions control is that all the internet protocol media endpoints (e.g. user terminals and other packet media endpoints) and devices on the edge of low-bandwidth links (i.e. in the Packetcable architecture, the CMTS) are required to fully support the reservation protocol (RSVP). In addition those endpoints and devices are required to support mechanisms to send and receive session identifier information from a call server. Also the call server and the devices at the edge of the low bandwidth link need to support the common open policy service (COPS) protocol. This is problematic because many existing communications networks are formed from equipment made by different manufacturers and where many of the nodes or endpoints do not support RSVP or COPS where needed. In addition, the Packetcable protocols require all layer-3 aware devices in a media path to support RSVP in order that call admission control can be effected. However, this is not the case for many communications networks. For example, FIG. 5 shows a low-bandwidth link 51 where nodes at either end of that link are only layer-2 aware devices. Therefore Packetcable protocol type call admission control mechanisms would not be effective. Other disadvantages of the Packetcable approach to call admission control include that no support for layer 2 flows is provided and the fact that all devices in the network which support RSVP are required to have some policy awareness.
The reservation protocol is defined in the Internet engineering task forces' request for comments (RFC) 2205 whilst COPS is defined in RFC 2748.
The known approach to call admissions control mentioned above which uses the Packetcable standards is now described in more detail. This approach involves the Common Open Policy Service (COPS) with RSVP. An example of a typical architecture for COPS and RSVP admissions control is given in FIG. 6 which shows two access networks connected to a core communications network via Policy Enforcement Points (PEPs). The core network comprises a policy decision point (PDP) and a call server. Using this approach, the originating and terminating parties make an admissions request to the call server using H.248, or any other suitable device control protocol such as media gateway control protocol (MGCP) or NCS where NCS is the Packetcable specific version of MGCP as indicated in FIG. 6. The call server then grants an appropriate service ticket to each of those parties. Next, the originating party or originating PEP spawns a network admission request through the network. A similar request is spawned by the destination party or destination PEP to request a call flow in the opposite direction and so provide a 2-way flow. The PDP receives the admission requests and forwards those to the call server.
The call server verifies the service tickets. The PDP decides whether to accept or refuse the request on the basis of available bandwidth on the low-bandwidth access link and if accepted, opens a reserved path for media for the new call. However, the COPS and RSVP approach is problematic because significant post dial delay occurs as a result of the admission process and also the other problems mentioned above with respect to the Packetcable approach apply; In addition, the means by which the call server and PDP communicate is not yet fully standardized.
More recently the Internet Engineering Task Force (IETF) have set up a working group to consider ways in which middleboxes can be controlled. The term “middlebox” is used herein to refer to an entity in a communications network which is associated with a low-bandwidth link and which is able to allow or disallow individual traffic flows over that link. For example, the middlebox may be a node connected to one end of a low-bandwidth link. Also, the middlebox may be part of a node which is not directly connected to one end of a low-bandwidth link but which is able to allow or disallow individual traffic flows over that link. The IETF working group is referred to as the MIDCOM (middlebox communications) working group. In the future it may be possible to use protocols developed by the MIDCOM working group to control such middleboxes in order that they themselves perform admissions control. However, these MIDCOM protocols are not yet developed and ratified. Indeed, we understand that the MIDCOM working group is currently working on the control of middleboxes for network address translation and firewall purposes, but not for admissions control purposes. It will be some time before this is the case and those protocols are deployed on all the required nodes in existing communications networks. In addition such MIDCOM methods would require a means by which a call server is automatically able to identify which middleboxes are relevant for a particular call. However, “middlebox discovery” mechanisms like this are not currently known.
Thus a means of providing call admission control which does not require using MIDCOM protocol methods, Packetcable protocols or COPS-RSVP approaches is required which is simple to implement, cost-effective and which is able to deal with particular situations such as conference calls, lawful intercept (known in North America as CALEA), and other potential call service situations is required.
The invention seeks to provide an improved method and apparatus for performing admissions control which solves or at least mitigates one or more of the problems mentioned above.
Further benefits and advantages of the invention will become apparent from a consideration of the following detailed description given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.